1. Field of the Invention
The present invention relates generally to computer operating systems, and more particularly, to techniques for intercepting I/O multiplexing operations involving cross-domain file descriptor sets.
2. Description of the Background Art
Operating systems such as UNIX(copyright) and Microsoft WINDOWS NT(copyright) are widely used in commercial computing systems. Among their many uses, these operating systems are commonly deployed on Internet and other network server computers. With the popularity and success of the Internet, operating systems for network servers are currently of great commercial importance.
Frequently, intercepting system calls that pertain to accessing files is desirable. Although operating systems include various internal resources for accessing a file system, it is often desirable to customize or extend operating system functionality for a particular use. Such customization allows a computer programmer, a network administrator, or a webmaster to utilize the operating system in a specific manner beyond the default system capabilities provided by the manufacturer of the operating system. The interception of system calls is one such method of extending and expanding operating system functionality.
A system call is a subroutine, the object code of which is located in the operating system. Such subroutines are normally called by processes (applications) executing under the control of the operating system. When executed, a system call performs some system operation, such as accessing a system hardware device or a software resource. Examples of operations executed by system calls may include reading data from a file, opening a network communication channel, and allocating computer memory to a specific process.
A system call vector table typically stores pointers to the executable code of the system calls. In order to make a system call, arguments are programmatically loaded into specific registers of the central processing unit (CPU) of the computer on which the operating system is executing. One of these arguments identifies the specific system call that is being made. This argument is typically in the form of a number that is an offset into the system call vector table. The other loaded arguments include parameters to be passed to the system call.
Once the arguments have been loaded, a software interrupt is normally generated, signaling to the operating system that a process is requesting execution of a system call. The operating system reads the registers, and executes the requested system call with the specified parameters. The system call executes and performs the desired functionality. If the system call generates a return value, it places the generated return value (or a pointer thereto) in a pre-designated register where it can be accessed by the calling process.
In order to intercept a system call, a pointer in the system call vector table to the system call is replaced with a pointer to alternative object code to be executed instead of the system call. As a result, when the operating system reads the system call vector table in response to the system call being requested, the operating system will read the pointer to the alternative object code, and the alternative object code will execute instead of the system call. The alternative object code is typically known as a xe2x80x9csystem call wrapper.xe2x80x9d
The interception of system calls providing access to the file system is useful in extending and customizing operating system functionality. For example, the interception of system calls may be used to manipulate operating system access privileges to provide security beyond that which is provided by the operating system. By intercepting system calls that provide access to the file system, processes can be prevented from deleting, modifying, creating, or even reading files. This is desirable, for example, when a user wishes to remotely execute a program residing on a web server, but does not want the remote program to be able to read or alter private data on the user""s computer. Today, Java(copyright) applets are commonly employed to provide such security. However, many programs that users wish to remotely execute are written in languages other than Java(copyright). System call interception has the potential to allow the safe execution of programs written in all languages.
The interception of system calls is known today, although it is an advanced programming technique. Nonetheless, a serious shortcoming limits the usefulness of intercepting system calls that provide access to the file system. That shortcoming is the inability to disambiguate between a file descriptor that is associated with a file stored on media (e.g., hard disk, optical disk, random access memory) and a file descriptor that is associated with a communication channel (e.g., referred to as a xe2x80x9csocketxe2x80x9d in UNIX(copyright)).
Many computer operating systems utilize file descriptors to provide access to file systems. Under such operating systems, a file is created by making a system call that creates a file and returns a file descriptor that is associated with the newly created file. Subsequently, the file is accessed via the file descriptor. Examples of file access operations include reading from a file, writing to a file, closing a file, and deleting a file. Such operations are typically conducted by making a designated system call, and passing the system call the file descriptor that is associated with the file being accessed.
Many commercially popular operating systems such as UNIX(copyright) and Microsoft WINDOWS NT(copyright) treat communication channels as files. In such an operating system, when a process makes a system call in order to establish a communication channel, the operating system returns a file descriptor. The communication channel is subsequently accessed via the file descriptor, in a similar manner as a file stored on media.
Commonly, the same system calls are made to perform the same access operations on both files stored on media and on communication channels. For example, under the UNIX(copyright) operating system, a read system call can be made in order to read data from either a file stored on media or from a communication channel. The system call itself has no information concerning the file type with which a file descriptor is associated. The system call simply executes instructions to access a file in a specific manner via a file descriptor. For example, the read system call executes instructions to copy a specific number of bytes from a file to a buffer in memory. The read system call does not distinguish between a file on media and a communication channel.
Likewise, a system call wrapper that executes when such a system call is intercepted conventionally has no mechanism for distinguishing between file types. For example, if the read system call is intercepted, the system call wrapper will execute whenever any process makes the system call to read data from any type of file. Thus, the system call wrapper will execute whenever a process attempts to read data from a file stored on media and also whenever a process attempts to read data from a communication channel.
Communication channels and files stored on media are inherently different, despite the fact that both are accessed via file descriptors. Thus, it is often desirable to intercept system calls that access a file stored on media, but not to intercept system calls that access a communication channel. Likewise, it is often desirable to intercept system calls that access a communication channel, but not to intercept system calls that access a file stored on media.
For example, as noted above, it is sometimes desirable only to intercept system calls that access files stored on media. The desired result is to prevent access to files stored on media, but not to prevent access to communication channels. At the same time, it may be undesirable to prevent write access to the communication channels of the client computer, because it would be desirable for the computer to be able to receive communication responses from web servers. However, intercepting every write system call and executing a system call wrapper in its place to prevent write access would prevent write access to both communication channels and to files stored on media.
Likewise, it is often desirable to intercept system calls that pertain to access of communication channels, but not to intercept system calls that pertain to access of files stored on media. For example, it may be desirable to disallow remote communication requests made to a certain computer, but at the same time allow local access to files stored on media of the computer. Again, because the same system call is used to access communication channels and files stored on media, the one can not be prevented and yet the other allowed without a means for disambiguating the file descriptors.
Moreover, under some operating systems, entities other than communication channels and files stored on media are treated as files, and hence accessed via file descriptors. For example, under the UNIX(copyright) operating system, hardware devices are designated by file descriptors. For the same reasons that it is desirable to disambiguate communication channel file descriptors from file descriptors that are associated with files stored on media, it is further desirable to disambiguate file descriptors that are associated with any type of file from those that are associated with any other type.
Accordingly, what is needed is a method for disambiguating file descriptors generally, and, specifically, for disambiguating file descriptors that are associated with files stored on media from file descriptors that are associated with communication channels. This allows for the selective interception of system calls that access one type of file or another.
Certain system calls, such as I/O multiplexing functions, may operate on multiple file descriptors, some of which may correspond to different file types. For example, the UNIX(copyright) select ( ) and poll ( ) system calls allow a process to instruct the kernel to wait for any one of a set of file descriptors to become ready for I/O. Such xe2x80x9cmultiplexingxe2x80x9d operations are extremely advantageous when a process needs to simultaneously handle multiple file descriptors, such as file descriptors for both interactive input (e.g., standard input) and network communication channels (e.g., sockets).
Most file accesses in UNIX(copyright) use a xe2x80x9cblockingxe2x80x9d I/O model. For instance, when a process is waiting to read from a communication channel, the process is normally put to sleep, i.e. blocked, until the data to be read becomes available. However, while the process is blocked, it may not normally receive data from another file or process. I/O multiplexing operations solve this problem by allowing a process to wait for any one of multiple events, and to wake the process only when one of the events has actually occurred.
As previously noted, communication channels and files stored on media are inherently different, despite the fact that both are accessed via file descriptors. Thus, it is often desirable to intercept system calls that access a file stored on media, but not to intercept system calls that access a communication channel, and vice versa.
However, in the context of an I/O multiplexing operation, a single system call (e.g., select or poll) operates on a mixed set of file descriptors, some of which may correspond to communication channels and others which may correspond to files stored on media. As used herein, a set of file descriptors of mixed file types is referred to as a xe2x80x9ccross-domainxe2x80x9d set.
In many cases, it would be desirable to intercept the processing of certain types of file descriptors within a single I/O multiplexing operation, while permitting other file descriptors to be handled in a conventional manner. However, such selective interception of functionality within a single system call presents even more difficulties than simply disambiguating file descriptors and deciding whether or not to execute alternative code within a system call wrapper.
Accordingly, what is needed is a method for intercepting I/O multiplexing operations involving cross-domain file descriptor sets, e.g., file descriptor sets including more than one file type. What is also needed is a method for intercepting I/O multiplexing operations wherein one type of file descriptor receives special processing not required by another type of file descriptor.
The present invention allows disambiguation of file descriptors, generally, and disambiguation of communication channel file descriptors from file descriptors that are associated with files stored on media, specifically. The disambiguation process involves storing indicators concerning file descriptors that are associated with a specific file type. When file descriptors are subsequently utilized to access files, the indicators are examined in order to determine the associated file type.
Another aspect of the invention relates to intercepting I/O multiplexing operations involving cross-domain file descriptor sets. In one embodiment, a system call for performing an I/O multiplexing operation on a set of file descriptors is intercepted by a system call wrapper. The system call wrapper then divides the set of file descriptors into a first subset corresponding to a first file type and a second subset corresponding to a second file type. This may be accomplished by referencing a table of indicators, as discussed above.
In one implementation, the system call wrapper establishes a private connection with a functional module. The connection may be identified by a virtual file descriptor, which is used in both the system call wrapper and the functional module for this purpose. The system call wrapper adds the virtual file descriptor, in one embodiment, to each of the first and second subsets of file descriptors.
After the subsets are modified, the system call wrapper and the functional module initiate system calls in parallel for performing separate I/O multiplexing operations on the first and second subsets of file descriptors. In response to the wrapper""s system call returning with an indication that at least one file descriptor is ready for communication, the wrapper performs an I/O operation (e.g., read or write) using the virtual file descriptor, which unblocks, if necessary, the functional module""s system call. Likewise, in response to the functional module""s system call returning with an indication that at least one file descriptor is ready for communication, the functional module performs an I/O operation (e.g., read or write) using the virtual file descriptor, which unblocks, if necessary, the wrapper""s system call.
The system call wrapper then combines the sets of file descriptors that are ready for I/O returned by the parallel system calls. Thereafter, the system call wrapper returns the combined sets of file descriptors to the calling process.
The above-described technique for intercepting an I/O multiplexing operation facilitates special handling of one or more of the file types. For example, special code may be included within the functional module for processing file descriptors relating to communication channels or other types of files. Moreover, the implementation of one or both of the I/O multiplexing operations may be modified to process certain types of file descriptors in non-standard ways. In certain embodiments, either the system call wrapper or the functional module may be associated with a customized communication protocol stack, which provides significant control over the handling of file descriptors.